home *** CD-ROM | disk | FTP | other *** search
/ Network Support Library / RoseWare - Network Support Library.iso / pressgen / tr316.bad < prev    next >
Text File  |  1992-09-14  |  3KB  |  76 lines
  1. The documentation accompanying the NetWare 3.11 update part# 136-001369-001 
  2. revision C has errors.
  3.  
  4. The documentation for TOKEN.LAN and TOKENDMA.LAN mentions that "A description 
  5. of each file follows."  There is no description of TOKEN.LAN following.
  6.  
  7. The documentation describes parameters NBR and NBT which alter the performance 
  8. of the TOKENDMA driver.  The usage and meaning of these parameters is not 
  9. documented.  With the omission of the TOKEN.LAN documentation, it is unknown 
  10. whether these parameters are used by this driver.
  11.  
  12. This omision is particularly important to NetWare for SAA clients.  The SAA 
  13. documentation states that the TOKENDMA driver will not work, and that 
  14. TOKEN.LAN, v3.16 or higher must be used.  Without documentation for the TOKEN 
  15. driver, errors are likely.
  16.  
  17.  
  18. The documentation for TOKENDMA.LAN describes a condition where the driver 
  19. pauses execution until beaconing stops.  This pause accounts for the queuing
  20. of ECBs.  I believe that the driver's behavior differs significantly from that 
  21. which is described in this documentation.
  22.  
  23. After adopting the TOKEN.LAN version 3.16, shipped with SAA, I recognized a 
  24. problem similar to that described in the update docs.
  25.  
  26. I am making some assumptions to help me work around the omissions in the 
  27. update documents.
  28.  
  29. I assume the behavior of v3.16 TOKEN is similar to v3.16 TOKENDMA with regards 
  30. to it's reaction to "Beaconing" errors.  I am also assuming that the queueing 
  31. of ECBs in the send queue might drive up the number of Packet Receive Buffers 
  32. and/or the Permanent Pool memory.
  33.  
  34. Given these assumptions, I have observed the following behavior of the 
  35. TOKEN.LAN v3.16 driver.
  36.  
  37. The driver appears to pause when a "RECEIVE CONGESTION ERROR" (RC error) 
  38. occours.  The driver does not appear to resume when the RC error is cleared.
  39. Several minutes after the node(s) reporting RC errors are removed, the server 
  40. still is unavailable.
  41.  
  42. In the presence of RC errors, the 3.16 TOKEN.LAN driver appears to pause.  The 
  43. Permanent memory pool continues to grow.  Packet Receive Buffers (PRBs) grow.  
  44. I have not waited for the PRBs to grow up to Max PRB.  
  45.  
  46. While the PRBs and Permanent memory grow, the server continues operating.  
  47. Only Token Ring activity has paused.  MONITOR continues to function as well as 
  48. do other NLMs.
  49.  
  50. If a connection is specified for clearing via MONITOR while the driver is 
  51. paused, monitor pauses.  With monitor paused, the server STILL functions.  If 
  52. MONITOR is unloaded from the console, the console pauses.  I would expect this 
  53. behavior if the driver were pausing.
  54.  
  55. Clearing the RC errors does not cause the driver to resume, at least not 
  56. quickly.  I waited approximately twenty minutes after eliminating all MAC 
  57. layer errors, but the driver remained paused.
  58.  
  59. The RC error is reported when a Token Ring interface's receive buffer is not 
  60. being serviced, and overflows.  This is a node error, not a ring error.  Token 
  61. Ring traffic continues in the presence of RC errors.  To the best of my 
  62. knowlege, this is not "Beaconing."
  63.  
  64. While the RC errors persist, the Token Ring continues to pass traffic.  Other 
  65. 3.11 servers running v3.13 TOKEN.LAN continue normaly, as do 2.2 servers.
  66.  
  67. A detailed description of these observations has been posted as a message with
  68. "TOKEN.LAN" 3.16 bugs" as it's subject.
  69.  
  70.  
  71. Any feedback is greatly appreciated.
  72.  
  73. Sincerely,
  74. Larry Rubanka
  75. 73465.643
  76.